This application is generally directed to synchronizing operations and, more particularly, to techniques for synchronizing operations between regions when a network connection fails.
Online transaction processing (OLTP) monitors support the concurrent execution of large numbers of instances of user transactions, known as tasks. These tasks can access the resources the OLTP monitor controls using an application programming interface (API) that the OLTP monitor provides. A user application program run by such a task can then issue API commands that the OLTP monitor then tries to satisfy. However, not all of the resources that an OLTP monitor controls may reside in a same region and often network connections are used to transmit an API command over a network to another OLTP monitor region.
Network messages have to conform to the protocol that a particular network supports. An OLTP monitor provides components that construct messages so that the messages conform to a specific network protocol, and which then interprets messages that arrive over a network for processing by the monitor. Several network connections can be supported between a pair of OLTP monitors, each using its own message protocol, to provide resilience to failure, or which support the transmission of different sets of API commands.
A user task can carry out updates to resources that are controlled by an OLTP monitor that it is running within, and also with those that have been accessed across a network in another OLTP monitor. Some tasks require that, before they end, all of these updates are kept in step with each other, and an OLTP monitor, such as CICS TS for z/OS (CICS is a trademark of International Business Machines Corporation), offers services to synchronize the set of updates that an individual task carries out. This process is referred to as ‘syncpointing’ in the CICS TS for z/OS Information Centre.
Specific components, often called recovery management connectors (RMCs), are used by OLTP monitors to handle the network messages that are exchanged during synchronizing operations. The components contain logic that links together the identity of a user task that is in the processing of carrying out synchronizing operations, the point in the synchronizing operation sequence that has been reached at any point in time, and the connection resources that the user task is making use of.
If the network connection fails during synchronizing operations then the OLTP monitors retain information on any tasks that they were in the process of synchronizing, so that the tasks can be completed once connectivity has been restored. Other tasks that start after a connection fails can make use of an alternative connection to the same partner OLTP monitor, but those that failed during synchronizing operations processing are prevented from doing so.
The interdependencies between a user task, the connection resources allocated to it, and the network protocol make it difficult to continue with the synchronizing operation when a connection of another type is available between the same pair of monitors, in much the same way that a driver that is used to access an Information Management System (IMS) database cannot be used to complete DB2 updates should the DB2 driver fail.
User tasks that cannot complete a synchronizing operation immediately may then retain locks on the resource updates that need to be finalized, preventing other user tasks from carrying out further changes to those resources.